Hallo zusammen. In der dritten Aufgabe solltet ihr eine vereinfachte Variante des Hadoop Distributed

File System, kurz HDFS, implementieren. Dazu schauen wir uns in diesem Video an,

wie verteilte Datensystemen allgemein und HDFS im Speziellen funktionieren.

Lokale Datensysteme solltet ihr alle kennen. Mit ihrer Hilfe adressiert man Daten auf dem

physikalischen Datenträger auf seinem Rechner oder Server. Einige bekannte Beispiele sind

FAT32 in Windows oder EXT4 und BTRFS für Linux. Wenn wir Daten über mehrere Rechner hinweg

verwalten wollen, brauchen wir aber mehr. Da gibt es zum Beispiel Netzwerk-Dateisysteme,

die es erlauben, Daten über Rechnergrenzen hinweg zu verwalten. Die entfernten Bereiche

werden dabei üblicherweise ins lokale Datensystem eingebunden und können möglichst transparent

wie ganz normale Dateien verwendet werden. Beispiel hierfür sind unter anderem das Network File System,

kurz NFS, das auch im ZIP läuft. Euer Home-Verzeichnis liegt hier nicht auf der

physikalischen ZIP-Kiste, auf der gerade eingeloggt seid, sondern auf einem zentralen Server. So könnt

ihr von jedem ZIP-Rechner auf euer Home zugreifen und habt immer eure aktuellsten Dateien.

Netzwerk-Dateisysteme sind schon einmal ein guter Anfang für einen Cloud-Betrieb,

haben aber einige Probleme. Es hängt hier halt alles von einem einzigen Server ab. Das ist sehr

fehleranfällig. Wenn das Netzwerk zu diesem einen Server gerade unzuverlässig ist oder abbricht,

haben wir potenziell keinen Zugriff mehr auf unsere Daten. Dasselbe gilt natürlich,

wenn der Server selbst fehlerhaft wird oder kaputt geht. Und selbst wenn man keine Fehler

im System hat, kann der Server leicht zum Flaschenhals werden. Stellt euch mal vor,

da steht ein kleiner Server auf den Tausende und Abertausende von Clients einpreschen,

die gerade irgendwelche Daten lesen wollen. Da geht der Server relativ schnell in die Knie

und die Clients werden ausgebremst. Diese Probleme löst man mit verteilten

Datensystemen. Üblicherweise wendet man hier das Prinzip Separation of Concerns,

auf Deutsch Trennung der Belange an, und trennt die Indizierung von der Datenverwaltung selbst.

Das aufwändige Schreiben und Lesen von Daten wird dabei von der Verwaltung

der Dateisystemindexes und der Metadaten getrennt. Der Index und die Metadaten werden

üblicherweise von einem einzelnen Server verwaltet, um ihn konsistenten zu vermeiden.

Die Daten selbst können aber über mehrere Server verteilt werden. Selbst bei einer hohen

Kleinglast kann das Dateisystem so durch geschickte Aufteilung die Bildung eines

Flaschenhalses verhindern. Datensätze werden zudem auf mehrere Server repliziert,

was die Auswahlsicherheit natürlich deutlich erhöht. Selbst Plattenverlust oder großflächige

Netzwerkprobleme sind so tolerierbar, ohne dass die Erreichbarkeit der Daten verloren geht.

Dadurch kann das Dateisystem recht starke Service Level Agreements, kurz SLAs, anbieten.

Dabei muss das Dateisystem natürlich weiterhin darauf achten, dass es Konflikte zwischen den

Clients auflöst. Wenn zwei Clients gleichzeitig dieselbe Datei versuchen abzuspeichern, darf nicht

auf Replikat A die Datei des ersten Clients und auf Replikat B die Datei des zweiten Clients das

Rennen gewinnen. Beispiele für verteilte Dateisysteme sind unter anderem Ceph, das

aus der Vorlesung bekannte Google File System und natürlich das von uns in der Übung betrachtete

HDFS. HDFS ist ein Teil von Apache Hadoop, einer umfangreichen Sammlung von Tools und Frameworks

zur Verarbeitung von großer Mengen von Daten in einem verteilten Skydeban-System. Neben HDFS

schauen wir uns in der nächsten Übung auch noch das MapReduce Framework und ZooKeeper aus Apache

Hadoop an. Betrachten wir nun zuerst die Konzepte und grobe Architektur von HDFS, bevor wir uns mit

den Details beschäftigen. HDFS arbeitet mit dem sogenannten Write Once, Read Many, kurz Worm-Konzept.

Daten können zwar beliebig oft gelesen werden, aber nur einmal geschrieben. Das Verändern,

Löschen oder Überschreiben eines Datensatzes ist nicht möglich. Ein Schreibaufruf verwendet

immer einen bisher ungenutzten Bereich des Speichers. Natürlich kann man trotzdem mehrere

Versionen einer Datei haben, diese werden aber separat voneinander gespeichert. Der Grund für

diese Designentschädung in HDFS ist wahrscheinlich, dass sich mit Worm einige Funktionalitäten eines

verteilten Dateisystems etwas leichter umsetzen lassen, da existierende Daten zum Beispiel keine

Synchronisation von Schreibaufrufen mehr brauchen. Das zweite Konzept von HDFS ist wenig überraschend,